Businesses increasingly rely on business processes to accomplish various tasks within the organization. The business software that is used to implement the business processes becomes critical to the organization. Some software (e.g., SAP business software of SAP AG of Walldorf, Germany) allows customization and modification of the business process applications. Changes to the business processes may be made frequently (e.g., weekly or even daily) in some organizations. Prior to implementing a change in the business process software, the organization would ideally verify/validate the change to ensure the change accomplishes what is desired, and does so correctly without interruption to the normal flow of the organization. However, current methods of verification of the business process changes are expensive, time-consuming, and often require tradeoffs between reliability and cost and/or time.
Currently, business software is tested in one of two ways: manually, or via record and playback/scripting. Manual testing involves having people sit in front of a controlled environment and run the proposed changed business software following written test instructions. Testing can only be performed by human interaction with the system on which the software is installed. Manual testing is deficient in that the testing time is very high, and the scope of tests possible is very small. The risk that an error will “make its way through” the testing is relatively high. The inefficiency and cost aspects to manual testing makes manual testing a generally unacceptable procedure.
Record and playback testing traditionally involves recording an entire sequence of activities that a particular participant in the business process would perform. However conventional record and playback requires that the test setup be an exact system duplicate of the recording. Variations between the systems frequently fail the testing. Additionally, the testing system must be extremely stable, given that changes to the system will fail the recording. Even in systems where the test does not fail for minor system changes, there is generally a limited access for test systems to business process content. The result of the lack of content access is less flexibility than would be preferred for most system operators. Furthermore, program scripting has a significant drawback in that specific tests must traditionally be written and adapted manually for every change. All current scripting tools have proprietary components that require specialists in the tool to implement. The cost of maintenance can become significant and possibly prohibitive. Thus, record and playback/scripting requires controlled conditions that are very difficult to produce, and difficult to duplicate. The complexity increases the cost of the procedure and does not guarantee the desired outcome.